3 of 14

There are two primary means of balancing the load across a cluster: "session-sensitive" and "true" load balancing. Session-sensitive load balancing occurs when a visitor is initially load-balanced to a particular server based upon traffic at that particular moment, then remains on that server for the duration of his or her session - even if another server in the cluster eventually carries a lighter load (see Figure 1). True load balancing occurs when, at any time during the session, a visitor may be receiving files from any server in the cluster. This has the advantage of balancing the load actively, using all servers in the cluster at all times for all visitors (see Figure 2).

Figure: 1 Session-sensitive load balancing

Figure: 2 True load balancing

ClusterCATS, as well as other clustering technologies, can function in both the true and session-sensitive modes I've described. With ClusterCATS it's as easy as changing one checkbox.

Some of you may disagree with my use of the somewhat biased term true load balancing. Your own experience may be that session-sensitive load balancing is just as good a choice when it comes to ease of use and performance.

I agree with you, up to a point: with a high-volume site, a session-sensitive clustering configuration might "all average out" and provide good performance for all the users. At any given moment a few servers may actually have more load than others, because more users have started a session and remained on a particular server longer. However, with a great many users, it might balance out in the end, without any noticeable performance issues. But there's no guarantee.

The Problem with Session-Scoped Variables in the Cluster
The heart of the problem is this: with each shift to a different server in a cluster, CF session variables are "lost." For example, if I log in to your application or Web site and end up on server www1 and you have set a session variable called "Session. IsLoggedIn" to keep track of me, that variable will be stored in the memory of the server www1. Since there's no central memory repository available to CF, if at any time during my session I'm load-balanced to server www2, that session variable will be lost because it doesn't exist in the memory of server www2.